在上一篇文章中，我整理了醫療資料交換標準從HL7 v2、HL7 v3、CDA到FHIR的發展，也了解到FHIR並不是突然出現的新名詞，而是建立在過去醫療資訊標準累積的經驗之上。
從今天開始，要正式進入這個系列的主角——FHIR。
FHIR看起來只有四個英文字母，但它的內容其實非常龐大，包含資料模型、API、搜尋、驗證、術語、文件及資訊安全等不同面向。
因此，今天先不急著研究複雜的規範，而是從名稱開始，建立幾個最重要的基本概念。
FHIR的發音類似英文的「fire」。
它的全名是：
Fast Healthcare Interoperability Resources
可以拆成四個部分理解：
| 英文 | 中文概念 |
|---|---|
| Fast | 快速、容易導入 |
| Healthcare | 醫療健康照護 |
| Interoperability | 互通性 |
| Resources | 資源 |
合在一起，可以將FHIR理解為：
一套以Resource為基礎，協助醫療資訊系統交換及使用健康照護資料的標準。
FHIR是由HL7 International制定的醫療資料交換標準。不過，FHIR不只是一種檔案格式，也不只是一套API，它還包含資料結構、交換規則、搜尋方式、代碼使用及擴充機制等內容。
FHIR名稱中的Fast，不代表醫療資料一定能在幾秒內傳送完成，也不是單純指網路速度很快。
它比較強調：
FHIR使用HTTP、RESTful API、JSON及XML等常見技術。對接觸過Web開發的人來說，這些概念通常比完全專屬於醫療領域的格式更容易開始學習。
例如，開發者可以透過一般的HTTP GET請求讀取病人資料：
GET /Patient/123
也可以用搜尋參數查詢特定姓名的病人：
GET /Patient?name=王小明
這些操作方式和許多Web API相似，因此可以使用瀏覽器、Postman或程式語言進行測試。
FHIR主要應用於醫療及健康照護領域，但它處理的資料並不只有醫師寫下的病歷內容。
FHIR涵蓋的資訊可能包括：
所以FHIR並不只服務單一科別或單一醫院系統，而是希望能在不同健康照護情境中交換資料。
Interoperability中文通常翻譯為「互通性」。
前幾篇文章中已經提到，兩套系統能夠互相傳送檔案，不代表已經真正達成互通。
完整的資料交換還需要考慮：
FHIR透過標準化的Resource、資料型別、代碼規則及交換方式，讓不同系統對資料有較一致的理解。
不過，採用FHIR並不代表所有互通問題都會自動消失。實際導入時，仍然需要處理院內欄位轉換、病人識別、標準代碼對應、權限管理及工作流程等問題。
FHIR最重要的概念之一就是Resource。
Resource可以理解為：
用來表達一種醫療或行政概念的標準化資料單位。
例如：
| Resource | 代表的內容 |
|---|---|
| Patient | 病人基本資料 |
| Practitioner | 醫療人員 |
| Organization | 醫療機構 |
| Encounter | 一次就醫事件 |
| Observation | 生命徵象、檢驗或觀察結果 |
| Condition | 疾病、問題或診斷 |
| MedicationRequest | 用藥醫令 |
| DiagnosticReport | 檢驗或檢查報告 |
| Appointment | 預約資料 |
| AllergyIntolerance | 過敏或不耐受紀錄 |
FHIR不會把所有病人資料全部塞進一個巨大的檔案，而是拆成不同Resource，再依照需要將它們連結起來。
可以將FHIR Resource想像成一組具有標準規格的積木。
假設王小明到醫院看診：
每一塊積木負責表達一種資料，再透過Reference建立關係。
例如：
Patient：王小明
├── Encounter：2026年9月3日家醫科門診
├── Observation：血壓測量結果
├── Condition：本次診斷
└── MedicationRequest：本次用藥醫令
如此一來，系統可以依照需求只取得特定資料，不一定每次都要傳送病人的所有紀錄。
以下是一份簡化的Patient Resource：
{
"resourceType": "Patient",
"id": "patient-001",
"identifier": [
{
"system": "https://example.org/mrn",
"value": "P001"
}
],
"name": [
{
"family": "王",
"given": ["小明"]
}
],
"gender": "male",
"birthDate": "2000-01-01"
}
這段資料包含：
resourceType：Resource類型id：FHIR Server中的Resource識別碼identifier：病歷號等業務上的識別資料name：姓名gender：性別birthDate：出生日期其中，resourceType是辨認FHIR Resource的重要欄位。
看到：
"resourceType": "Patient"
就代表這是一筆Patient Resource。
如果是：
"resourceType": "Observation"
則代表這是一筆Observation Resource。
不同Resource記錄的內容不同，但它們仍具有一些共同概念。
每一筆FHIR資料都會指出自己是哪一種Resource。
"resourceType": "Patient"
Resource可以使用id識別FHIR Server中的特定資料。
"id": "patient-001"
Resource可以包含版本、更新時間及Profile等資訊。
"meta": {
"versionId": "1",
"lastUpdated": "2026-09-03T09:00:00Z"
}
FHIR Resource可以包含text，提供讓人閱讀的摘要內容。
每種Resource會定義自己的欄位。例如Patient有姓名和生日，Observation則有檢驗項目及測量結果。
如果標準欄位無法滿足特定需求，FHIR也提供Extension機制。不過擴充仍然需要清楚定義，不能隨意新增一個只有自己看得懂的欄位。
FHIR Resource可以使用不同格式表示，常見的包括：
同一筆Patient資料可以表示成JSON，也可以表示成XML。
{
"resourceType": "Patient",
"id": "123"
}
<Patient xmlns="http://hl7.org/fhir">
<id value="123"/>
</Patient>
兩者表達的是相似概念，只是使用不同語法。
由於JSON在Web API中很常見，而且相對容易閱讀，本系列後續將以JSON作為主要格式。
FHIR定義了如何透過RESTful API操作Resource。
常見操作包括：
| 操作 | HTTP方法 | 用途 |
|---|---|---|
| Read | GET | 讀取一筆Resource |
| Search | GET | 搜尋符合條件的Resource |
| Create | POST | 建立新的Resource |
| Update | PUT | 更新Resource |
| Delete | DELETE | 刪除Resource |
| History | GET | 查看歷史版本 |
例如，要讀取ID為123的Patient：
GET https://example.org/fhir/Patient/123
要搜尋姓氏為Wang的Patient：
GET https://example.org/fhir/Patient?family=Wang
要建立Patient，則可能使用：
POST https://example.org/fhir/Patient
並在Request Body中放入Patient Resource。
這些操作會在後續文章中搭配Postman一步一步實作。目前只需要先知道：
Resource定義資料的內容，RESTful API則提供操作及交換Resource的方式。
剛開始接觸FHIR時，我曾經容易把它想成一套可以直接安裝的醫療資訊系統。
實際上，FHIR不是：
FHIR是一套標準。
不同醫院、政府機關或系統廠商可以依照FHIR規範開發自己的FHIR Server、API及應用程式。
因此，兩個系統即使都使用FHIR，也需要確認彼此使用的FHIR版本、Profile、代碼系統及支援功能。
FHIR的規範需要適用於許多國家及醫療情境，因此Resource通常保留一定的彈性。
但是，實際使用時，可能需要更明確地限制資料結構。
例如，某個應用情境可能規定：
這種針對特定情境調整及限制FHIR Resource的規則，就會使用Profile來表達。
臺灣也有自己的FHIR核心實作指引，稱為TW Core IG，會依照臺灣的使用需求定義相關Profile。
Profile及TW Core IG會在後續文章中另外介紹，目前可以先理解為：
Resource提供共同基礎，Profile則針對特定情境訂出更明確的使用規則。
FHIR有不同版本，例如：
不同版本的Resource及欄位可能有所差異。
這個系列主要使用FHIR R4，也就是4.0.1版本，原因是臺灣核心實作指引TW Core IG目前是以FHIR R4.0.1為基礎。
因此，後續查看FHIR官方文件及準備JSON範例時，會盡量確認使用的是R4頁面，避免不小心混用其他版本的規則。
假設兩個人想交換包裹。
只知道「要寄包裹」還不夠，雙方還需要知道：
套用到FHIR：
因此，FHIR不只關心資料能不能傳送，也關心資料是否具有共同結構，能否被接收系統理解及使用。
今天從FHIR的完整名稱開始，認識了五個重要概念：
FHIR並不是一套完整的醫院資訊系統，也不只是單一資料格式。它提供了一套描述及交換醫療資料的共同規則，讓不同系統可以用較一致的方式溝通。
下一篇將專門深入介紹FHIR Resource，看看它為什麼像積木，以及一筆Resource通常包含哪些部分。
Day 7｜FHIR的Resource到底是什麼？
HL7 FHIR R4：FHIR Overview
https://hl7.org/fhir/R4/overview.html
HL7 FHIR R4：FHIR Summary
https://hl7.org/fhir/R4/summary.html
HL7 FHIR R4：Resource
https://hl7.org/fhir/R4/resource.html
HL7 FHIR R4：RESTful API
https://hl7.org/fhir/R4/http.html
衛生福利部臺灣核心實作指引（TW Core IG）
https://twcore.mohw.gov.tw/ig/twcore/
iThome鐵人賽
看影片追技術